Skip to content

bugfix: activity log and journal description not updating without pag…#231

Merged
TatjanaTrajkovic merged 2 commits into
mainfrom
bugfix/log_historik_frontend
Apr 22, 2026
Merged

bugfix: activity log and journal description not updating without pag…#231
TatjanaTrajkovic merged 2 commits into
mainfrom
bugfix/log_historik_frontend

Conversation

@TatjanaTrajkovic

@TatjanaTrajkovic TatjanaTrajkovic commented Apr 22, 2026

Copy link
Copy Markdown
Contributor

…e reload (#219)

Summary by CodeRabbit

  • Bug Fixes
    • Improved reliability and consistency of activity log updates when modifying case details.
    • Fixed cancel button behavior to properly reset unsaved changes in case detail form.

@TatjanaTrajkovic TatjanaTrajkovic self-assigned this Apr 22, 2026
@TatjanaTrajkovic TatjanaTrajkovic added bug Something isn't working frontend labels Apr 22, 2026
@coderabbitai

coderabbitai Bot commented Apr 22, 2026

Copy link
Copy Markdown

Warning

Rate limit exceeded

@TatjanaTrajkovic has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 48 minutes and 0 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 48 minutes and 0 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8d25cb15-4327-417b-a837-a8437f1402e3

📥 Commits

Reviewing files that changed from the base of the PR and between 2a4731f and 4ab4000.

📒 Files selected for processing (1)
  • frontend/src/pages/CaseDetail.jsx
📝 Walkthrough

Walkthrough

The component refactors activity-log refresh logic by introducing a centralized refetchActivityLog() helper function, consolidating duplicated timeline update calls across multiple mutation handlers. Edit state handling was adjusted to properly reset edited fields and display them during non-edit mode. Effect dependency was refined to re-run only on case ID changes.

Changes

Cohort / File(s) Summary
Activity Log Refresh Consolidation
frontend/src/pages/CaseDetail.jsx
Introduces refetchActivityLog() helper to centralize timeline refresh logic. Updates status change, case close, message send, attachment upload/delete, and record save handlers to call this helper, eliminating duplicated getLogsByRecord/setTimeline inline calls.
Edit/View State Management
frontend/src/pages/CaseDetail.jsx
Modifies "Avbryt" action to reset editedTitle/editedDescription from caseData. Non-edit UI now displays editedTitle/editedDescription instead of caseData properties directly.
Effect Dependency Optimization
frontend/src/pages/CaseDetail.jsx
Removes isEditing from effect dependency array. Effect now re-runs only when caseData?.id changes, preventing unnecessary re-syncing of local editable fields.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~18 minutes

Possibly related PRs

Poem

🐰 A tangled timeline thread is spun,
Now woven tight—one clear refrain,
State and action dance as one,
No duplicate trails remain,
The edit realm is fresh and true!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title directly addresses the main change: fixing activity log and journal description not updating without page reload, which aligns with the PR's core objective.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch bugfix/log_historik_frontend

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@TatjanaTrajkovic TatjanaTrajkovic linked an issue Apr 22, 2026 that may be closed by this pull request

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
frontend/src/pages/CaseDetail.jsx (1)

68-78: Nice consolidation.

Centralizing the activity-log refresh into refetchActivityLog() removes the duplicated getLogsByRecord + setTimeline plumbing from each mutation handler, and the prev.filter(i => i.type !== 'ACTIVITY') approach correctly preserves locally-appended COMMENT entries added optimistically in handleSendMessage.

One optional hardening: if the user navigates away (caseData.id changes) while a refetch is in flight, the late setTimeline could write logs for the previous record into the new view. A simple guard is to capture the id and bail out on mismatch:

Optional: ignore stale in-flight responses after caseData.id changes
     const refetchActivityLog = async () => {
+        const requestedId = caseData.id;
         try {
-            const logsRes = await activityService.getLogsByRecord(caseData.id);
+            const logsRes = await activityService.getLogsByRecord(requestedId);
+            if (requestedId !== caseData.id) return;
             setTimeline(prev => [
                 ...prev.filter(i => i.type !== 'ACTIVITY'),
                 ...logsRes.data.map(l => ({ ...l, type: 'ACTIVITY' }))
             ].sort((a, b) => new Date(b.createdAt) - new Date(a.createdAt)));
         } catch (error) {
             console.error("Kunde inte uppdatera aktivitetsloggen:", error);
         }
     };
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@frontend/src/pages/CaseDetail.jsx` around lines 68 - 78, refetchActivityLog
can race with navigation: capture the current case id at the start (const
currentId = caseData.id) and before calling setTimeline validate that
caseData.id === currentId; if not, return early to avoid writing logs for a
stale case. Update the refetchActivityLog function (and any callers like
handleSendMessage that rely on it) to perform this guard using the captured id
before merging logs via setTimeline so late responses don't overwrite the
timeline for a newly-selected case.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@frontend/src/pages/CaseDetail.jsx`:
- Around line 25-31: The header is still reading caseData.title while the
journal uses editedTitle/editedDescription and handleSaveRecord doesn't update
local state or notify the parent; fix by making the component use the same local
state for both header and body and keeping that state in sync after saves:
change the header rendering (where it currently uses caseData.title) to use
editedTitle/editedDescription/localStatus, update the sync useEffect (currently
watching [caseData?.id]) to watch the relevant fields (e.g., [caseData?.id,
caseData?.title, caseData?.description, caseData?.status]) so incoming server
updates reset local state, and modify handleSaveRecord to apply the server
response to setEditedTitle/setEditedDescription/setLocalStatus and/or call an
optional onUpdated callback passed from the parent to trigger a refetch; ensure
setEdited* is called with the saved values so header/body remain consistent.

---

Nitpick comments:
In `@frontend/src/pages/CaseDetail.jsx`:
- Around line 68-78: refetchActivityLog can race with navigation: capture the
current case id at the start (const currentId = caseData.id) and before calling
setTimeline validate that caseData.id === currentId; if not, return early to
avoid writing logs for a stale case. Update the refetchActivityLog function (and
any callers like handleSendMessage that rely on it) to perform this guard using
the captured id before merging logs via setTimeline so late responses don't
overwrite the timeline for a newly-selected case.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d0f78813-33b1-4310-a5c3-46942004faa7

📥 Commits

Reviewing files that changed from the base of the PR and between 36f1bcb and 2a4731f.

📒 Files selected for processing (1)
  • frontend/src/pages/CaseDetail.jsx

Comment thread frontend/src/pages/CaseDetail.jsx
@TatjanaTrajkovic
TatjanaTrajkovic merged commit 86978a3 into main Apr 22, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working frontend

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Logg & Historik uppdateras inte efter åtgärder i ärendet

1 participant